E-이스티오 설정 트러블슈팅하기

#cncf/istio #topic/explain #cncf/istio/observability/kiali #command/istioctl #cncf/istio/istio-operator #study/cloudnet/istio1

개요

네트워크 통신 환경에서는 설계 상의 결함, 트래픽 지연, 설정 휴먼 에러 등의 많은 문제가 발생할 수 있다.
이스티오의 존재 이유는 이러한 문제들을 자동으로 해결할 수 있는 환경을 만드는 것이다.
대표적인 자동화된 복원 전략으로는 간헐적 에러에 대한 재시도, 타임아웃 적용, 서킷 브레이커 등이 있을 것이다.
그런데 이스티오의 자체 기능으로 해결할 수 없는 이슈들이 있을 수 있다.
대표적으로 사람의 잘못된 설정, 이스티오 자체의 버그나 이슈는 이스티오가 대응할 수 있는 문제가 아니다.
이 중에서 의도하지 않은 휴먼 에러, 잘못된 설정을 빠르게 탐지하는 방법을 알아보자.

이스티오에서는 잘못된 설정을 확인할 수 있도록 분석하는 툴을 제공하기에 사실 처음 리소스를 만들 때 문제를 인지할 수 있다.
이번 실습에서는 전반적인 트러블슈팅 가이드라인을 제공하려는 것이기에 문제가 발생하고 뒤늦게 원인을 진단해야 하는 상황이라고 가정한다.

가이드라인

이슈 포인트 구분

트래픽 흐름을 구분지어 문제가 발생할 수 있는 구간은 대충 이렇게 된다.

istiod에서 데이터 플레인으로 상태 전달
- 컨트롤 플레인의 설정이 데이터 플레인에 반영되지 않은 상황
게이트웨이에서 트래픽 인입
프록시와 앱 간의 트래픽
서비스 디스커버리
서비스 간 트래픽

발생한 문제를 해결할 때 각 부분들을 분리시켜 파악하면 원인을 명확하게 규명하는데 도움될 것이다.

컨트롤 플레인과 데이터 플레인 동기화 상태

여기에서 필수적으로 먼저 살필 것은 설정한 내용이 데이터 플레인에 제대로 반영됐는지 여부이다.
이스티오는 컨트롤 플레인의 설정을 동기적으로 데이터 플레인에 반영시키지 않는다.
이스티오는 설계 상 궁극적 일관성(eventual contistency)을 지향한다.

이는 컨트롤 플레인에서 인지하는 상황과 데이터 플레인의 상태가 항상 일치하는 상태가 아닐 수 있다는 걸 시사한다.
마치 쿠버네티스가 컨트롤러를 통해 희망 상태와 현재 상태를 맞춰나가는 것과 비슷한 것이다.
즉 관리자가 제대로 설정을 했더라도 이것이 바로 적용되지 않았기 때문에 문제가 발생할 가능성도 고려해야 한다는 것이다.

만약 운영 설정이 제대로 됐는데 이것이 데이터 플레인에 반영이 되지 않은 상황이라면, 컨트롤 플레인 성능 이슈, 혹은 버그일 가능성이 높으며, 이때부터는 컨트롤 플레인에서 문제를 찾는 방향으로 나아가야 한다.

이후

트러블슈팅 접근 순서에 있어서 이후의 구간들을 구분할 필요는 없다.
해당 포인트들은 문제의 원인을 규명하기 위해 나누는 것이고, 트러블슈팅은

메시 설정 확인
프록시 설정 적용 정보 확인
어플리케이션 모니터링 - 로그, 메트릭, 트레이싱..

이런 순서로 나가는 게 좋다.

세팅

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: myk8s
nodes:
- role: control-plane
  image: kindest/node:v1.32.2
  extraPortMappings:
  - containerPort: 30000
    hostPort: 30000
  - containerPort: 30001
    hostPort: 30001
  - containerPort: 30002
    hostPort: 30002
  - containerPort: 30003
    hostPort: 30003
  - containerPort: 30004
    hostPort: 30004
  - containerPort: 30005
    hostPort: 30005
  - containerPort: 30006
    hostPort: 30006
  - containerPort: 30007
    hostPort: 30007
  extraMounts:
  - hostPath: ../book-source-code-master
    containerPath: /istiobook
networking:
  podSubnet: 10.10.0.0/16
  serviceSubnet: 10.200.1.0/22

kind에서 조금 달라진 세팅으로, 서브넷 대역을 넓혀둔다.
이후에 여러 개의 서비스를 만든 상태에서 최적화를 할 것이기 때문이다.

helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
helm install metrics-server metrics-server/metrics-server --set 'args[0]=--kubelet-insecure-tls' -n kube-system

Metrics Server도 설치하여 메트릭을 쉽게 볼 수 있도록 세팅했다.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  profile: default
  components:
    pilot:
      k8s:
        env:
          - name: PILOT_FILTER_GATEWAY_CLUSTER_CONFIG
            value: "true"
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        service:
          type: NodePort
          ports:
          - name: http
            port: 80
            targetPort: 8080
            nodePort: 30000
          - name: https
            port: 443
            targetPort: 8443
            nodePort: 30005
          externalTrafficPolicy: Local
  meshConfig:
    outboundTrafficPolicy:
       mode: ALLOW_ANY
    enableTracing: true
    defaultProviders:
      metrics:
        - prometheus
      tracing: []
    accessLogFile: /dev/stdout
  values:
    global:
      proxy:
        privileged: true
    pilot:
      env:
        ENABLE_NATIVE_SIDECARS: true

이스티오 오퍼레이터 양식에서는 distroless를 빼고 프록시 컨테이너의 권한을 높여주었다.

kubectl apply -f addons
kubectl create ns istioinaction
kubectl label namespace istioinaction istio-injection=enabled
kubectl ns istioinaction

기본 네임스페이스를 생성하고..

apiVersion: v1
kind: Pod
metadata:
  name: debug
spec:
  volumes:
    - name: local
      hostPath:
        path: "/istiobook"
  containers:
    - name: debug
      image: nicolaka/netshoot
      command: [sh, -c, "sleep 60d"]
      volumeMounts:
        - mountPath: /istiobook
          name: local
  terminationGracePeriodSeconds: 0

디버그용 파드도 띄워둔다.

잘못 설정하기

이스티오 버츄얼서비스에서 subset 필드를 사용하기 위해서는 대상이 될 클러스터 관련 이스티오 데스티네이션룰을 만들어야만 한다.
어리숙한 관리자 Z는 이를 간과하고 버서를 만들고야 말았다.

kubectl apply -f services/catalog/kubernetes/catalog.yaml -n istioinaction # catalog v1 배포
kubectl apply -f ch10/catalog-deployment-v2.yaml -n istioinaction # catalog v2 배포
kubectl apply -f ch10/catalog-gateway.yaml -n istioinaction # catalog-gateway 배포
kubectl apply -f ch10/catalog-virtualservice-subsets-v1-v2.yaml -n istioinaction

보다시피 서브셋을 설정해서 가중치 라우팅을 하고 있다.

그러나 데룰이 없기 때문에 실제로 위 버서의 영향을 받는 엔보이들은 적합한 클러스터 엔드포인트를 찾을 수 없다.

while true; do curl -K curl.conf http://catalog.istioinaction.io:30000/items -w "\nStatus Code %{http_code}\n"; sleep 1;  done

에러를 확인할 수 있도록 반복 접근을 걸어둔다.

접근할 수 있는 서비스가 없다고 출력되는 것을 볼 수 있다.
클라이언트는 서비스를 정상적으로 이용할 수 없는 상태이다!
관리자 Z는 어떻게 문제 원인을 추적해야할까?

이스티오를 쓸 줄 모르는 Z는 흔히 쿠버네티스에서 하던 방식을 먼저 써본다.

k stern -l app=catalog -c istio-proxy

아무리 트래픽을 날려도 실제로 카탈로그의 로그에는 아무런 반응이 없다.

k logs -n istio-system istio-ingressgateway-6567675ffd-6w7jx

구체적인 에러는 게이트웨이에서 관찰할 수 있다.

[2025-05-13T11:42:43.280Z] "GET /items HTTP/1.1" 503 NC cluster_not_found - "-" 0 0 0 - "172.18.0.1" "curl/8.5.0" "49f686eb-2cea-429e-89da-24f4d53736b9" "catalog.istioinaction.io:30000" "-" - - 10.10.0.7:8080 172.18.0.1:38482 - -

NC는 NoClusterFound를 뜻하며, 서비스 레지스트리에 없는 클러스터라는 뜻이다.^[1]
이런 식으로 일일히 데이터 플레인 서비스에 들어가서 상황을 체크하는 것은 굉장히 비효율적일 것이다.

이스티오 자체 레벨에서 트러블 슈팅하기

동기화 상태 파악 - istioctl proxy status

관리자 Z는 일단 현재 자신의 설정이 제대로 데이터 플레인에 적용된 것인지 확인할 필요가 있다.
이스티오는 컨트롤 플레인의 설정이 동기적으로 데이터 플레인에 반영되는 것이 아니기 때문이다.

이걸 가장 쉽게 확인할 수 있는 방법은 proxy status.

istioctl ps

이 명령어는 이스티오 내 데이터 플레인들이 컨트롤 플레인의 설정과 동기화됐는지 확인한다.
최근 언제 동기화가 됐는지도 출력된다.
만약 여기에 STALE이라고 표시된다면, 컨트롤 플레인의 설정을 해당 엔보이가 제대로 반영했는지 확인하지 못한 상황이라는 것이다.

istiod의 과부하
네트워크 이슈로 통신하지 못함
그냥 버그..

이런 원인으로 STALE이 발생할 수 있고, 이때는 현재 서비스 메시가 잘 돌아가고 있는지를 확인해야 한다.

ps에 아예 엔보이가 붙은 파드를 특정해서 넣으면 설정이 어떤 식으로 매칭되고 있는지도 확인할 수 있다.

메시 설정 이슈 파악 - istioctl analyze, describe

현재 상황에서는 동기화로 문제가 발생하고 있지 않다는 것을 알 수 있었다.
이제 휴먼 에러가 발생한 것은 아닌지 확인해봐야 하는데, 이때도 istioctl을 유용하게 사용할 수 있다.

istioctl analyze

analyze는 보다시피 아예 현재 메시에서 사용자가 잘못 설정한 것을 알려주는 막강한 명령어이다.
웬만해서 이것만 보고도 잘못 설정한 것은 다 찾을 수 있다.
물론 이건 오류를 잡아내는 용이고 관리자가 의도한 대로 설정을 하지 않은 모든 것을 잡아주는 것은 당연히 아니다.

에러 코드 0101은 ReferenceResourceNotFound 코드인데, 현재 사진에서는 서브셋을 나눴어야할 데룰이 없다고 이야기하고 있다.
에러 코드에 대한 정보는 공식 문서에 나와있으니 참고하자.^[2]
근데 분류가 꽤나 나이브한 것 같아서 그냥 뜨는 에러 메시지를 보고 캐치하는 게 더 낫지 않나 싶은 생각이 들긴 한다.

이제 슬슬 원인 파악이 끝났으니 현 상황을 해결할 수 있는 리소스를 넣어본다.

istioctl analyze ch10/catalog-destinationrule-v1-v2.yaml -n istioinaction

analyze는 파일을 인자로 주면 해당 리소스를 적용했을 때 어떤 문제가 있을지, 혹은 제대로 동작할지 체크하는 것도 가능하다.

istioctl analyze -L

구체적으로 어떤 것을 봐주는지 파악하고 싶다면 이렇게 넣어보자!

그렇다면 이번에는 describe를 써본다.

istioctl x describe pod catalog-v2-7cc6f578cd-zq9n6

참고로 x는 experimental의 약자이다.

describe로는 워크로드(정확하게는 파드를 특정한다)를 대상으로 설정을 분석할 수 있다.
크게 다음의 정보가 제공된다.

어떤 서비스인지
어떤 버서와 데룰의 적용을 받는지
mtls가 요구되는지

여기에서도 서브셋이 설정되지 않았다는 경고를 보여주는 것이 확인된다.
특정 워크로드에 문제가 있는 것을 인지하고 있는 상황이라면 describe가 유용할 것이다.

서비스를 기준으로 describe를 하는 것도 가능한데, 이에 해당하는 워크로드를 보여주지는 않는다.

추가 - 키알리로 간단하게 확인하기

키알리에서 이스티오 설정 상태를 간단하게 확인하는 방법도 있다.
현재의 경우는 설정에 문제가 있었기 때문에 이렇게 확인할 수 있다.
설정 문제가 아니라면 트래픽 그래프를 보면서 문제가 발생하는 지점을 찾고 추적해나갈 수 있을 것이다.

이 문제는 서브셋 설정이 없어서 발생하는 문제라는 것을 파악할 수 있다.
키알리에서 제공하는 각종 검증 상태 코드는 여기에 모여있다.^[3]
관련한 문제로 클러스터에서 문제가 발생하고 있다면 유용하게 활용할 수 있을 것이다.
istioctl analyze보다는 더 자세하게 코드를 분류하고 있어서 이것도 디버깅의 수단으로 꽤나 유용하다.

프록시에 적용된 설정 정보 확인 - istioctl proxy config

위 방식에서 문제가 발견되지 않는다면, 최소한 메시 설정 자체가 문제를 일으키는 상황은 아니라고 결론을 내릴 수 있다.
그렇다면 다음으로는 적용된 설정이 의도한대로 적용되지 않았는지 데이터 플레인의 세부 정보를 확인해야 한다.

엔보이에서는 15000 포트로 관리자 페이지를 노출하고 있으면 이를 통해 여러 설정들을 확인할 수 있다.

keti catalog-5899bbc954-8nwpb -- curl localhost:15000/config_dump | wc -l

전체 설정 정보를 보고 싶다면 config_dump를 뜨면 되는데, 보다시피 유달리 설정이 안 된 메시에서의 기본 덤프 파일 길이만 해도 굉장히 폭력적이다..
애초에 엔보이는 자동화된 서비스 메시 환경에서 구동할 것을 감안하고 설계됐기에 설정 파일을 사람이 건드려서 보라고 만든 게 아니다.

대신 해당 설정들을 분할해서 포인트를 나누어 확인하는 방법이 존재하니, 그것이 바로 istioctl proxy config이다.

istioctl pc

엔보이의 설정을 직접 보고자 할 때는 여태 많이 활용했던 proxy-config 명령어를 활용해주면 적절히 원하는 부분을 분간해서 설정 파일을 뜯어볼 수 있다.
이 부분은 여태 많이 했기에 일일히 전부 실습하진 않겠다.
대신 각각이 어떤 내용을 담고 있고 어떨 때 확인하는 게 좋을지 정리하자면,

bootstrap - 초기 엔보이 구동 시 적용됐던 설정파일 정보
- 서비스 메시 구축 시 설정이 어떤 식으로 적용되고 있는지 확인할 때 유용하다.
cluster - 클러스터(다운스트림) 정보
- 데스티네이션룰이 핵심적으로 적용되는 영역이다.
- 엔보이가 추적하고 있는 서비스 레지스트리를 검색할 때 유용하다.
ecds - 확장 설정 정보
- Istio EnvoyFilter, Istio WasmPlugin 등을 활용하고 있을 때 해당 설정이 들어갔는지 확인할 때 쓴다.
endpoint - 엔드포인트 정보
- 레지스트리에 등록된 각 서비스의 세부 워크로드들이 추적되고 있는지 확인할 수 있다.
listener - 리스너 정보
- 현재 이 서비스가 어느 경로를 통해 트래픽을 받고 tls 설정 등을 적용하고 있는지 확인할 수 있다.
- 많이 볼 일은 없는 것 같다.
log - 로그 수준 정보
- 엔보이 어드민에서 설정할 수 있는 로그 수준 세팅을 이걸로도 할 수 있다.
- 로그를 출력하는 명령어는 아니니 주의하자.
rootca-compare - 파드 간 root ca 비교
- mtls를 설정할 때 제대로 적용되지 않는다면 두 파드를 넣어 비교를 해보는 것도 방법이겠다.
route - 라우트 정보
- 버츄얼 리소스가 핵심적으로 적용되는 영역이다.
- 라우팅 설정, http 영역의 설정이 적용되는지 확인할 수 있다.
secret - 인증서 정보
- tls 통신을 할 때 제대로 인증서가 주입됐는지 유용하다.

이렇게 분할해서 본다고 해도 막상 보면 주어지는 정보가 ㅎㄷㄷ 하다.
그래서 추가 인자로 포트, fqdn 등으로 정확하게 추적하고자 하는 대상을 한정지어 쿼리를 하는 편이 좋다.
또한 그냥 이렇게 보면 간략한 정보만이 표시되지만,

json으로 출력을 걸어서 보면 훨씬 더 자세한 정보가 출력되니 이걸 적극 활용하면 도움이 된다.

어플리케이션 이슈 파악

이스티오 단에서 발견하고 대응해야 할 방법들을 알아봤다.
여기에서도 문제가 발견되지 않는다면, 이제는 어플리케이션 자체에 문제가 있을 가능성을 염두하고 접근해야 한다.
이스티오를 활용해서 어플리케이션의 문제를 어떻게 빠르게 파악하고 분석할 수 있을까?
이스티오의 관측가능성을 적극 활용해본다.

세팅 - 응답이 느린 어플리케이션 만들기

이 세팅에서는 일부러 간헐적으로 응답이 느려지는 파드를 만든다.
이전에 세팅한 데룰 관련 문제는 없애두길 추천한다!

CATALOG_POD=$(kubectl get pods -l version=v2 -n istioinaction -o jsonpath={.items..metadata.name} | cut -d ' ' -f1)
echo $CATALOG_POD

# 해당 파드에 latency (지연) 발생하도록 설정
kubectl -n istioinaction exec -c catalog $CATALOG_POD \
-- curl -s -X POST -H "Content-Type: application/json" \
-d '{"active": true, "type": "latency", "volatile": true}' \
localhost:3000/blowup ;

예제 파일에서는 blowup 엔드포인트에 미들웨어 설정이 담겨 있어 여기에 지연을 부여할 수 있다.

while true; do curl -K curl.conf http://catalog.istioinaction.io:30000/items -o /dev/null -w "\nStatus Code %{http_code}\n"; sleep 0.5;  done

조금 더 명확하게 확인할 수 있게 요청 주기를 줄였다.

v2로 가는 요청은 1초 가까이 지연되고 있다.

p50까지는 이냥저냥한 시간이 나오지만, 95부터는 확실하게 요청이 느리게 처리되고 있다.

이 정보는 그라파나 메시 대시보드에서도 확인할 수 있다.
여기에 SLO 달성을 위해 타임아웃 시간을 짧게 잡도록 설정을 한다고 해보자.
그러면 느린 응답은 트래픽 실패로 받아들여지게 될 것이다.

kubectl patch vs catalog-v1-v2 -n istioinaction --type json \
-p '[{"op": "add", "path": "/spec/http/0/timeout", "value": "0.5s"}]'

이제 간헐적으로 에러가 발생하는 것을 확인할 수 있다.
직접 에러가 날 상황을 만들어냈기 때문에 세팅하면서 문제 색적이 됐는데, 다른 이슈로 문제가 있다고 하더라도 결국 키알리나 그라파나를 이용해서 문제 상황을 확인하게 될 것이다.

어떤 문제가 일어나고 있다는 것은 관측가능성 설정을 잘 해뒀다면 빠르게 확인할 수 있을 것이다.
관건은 해당 문제가 왜 일어나는지 찾아내는 것이다.

엔보이 로그 분석

처음에는 역시 로그를 보는 게 근본..
어리숙한 Z가 처음 사용했던 방법을 조금 더 세밀하게 이용해본다.

k logs -n istio-system istio-ingressgateway-6567675ffd-g6knh

엔보이의 기본 로그는 이런 모양을 가지고 있다.
굉장히 많은 정보를 담고 있어서 직관적이지는 않은 것 같다.

[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%"\n

로그에서 각 부분은 다음의 의미를 가진다.
일일히 위 양식을 외우기는 힘들 것 같고, 아직 익숙하지 않다면 조금 더 인간 친화적으로 출력을 바꿀 수 있다.

  meshConfig:
    outboundTrafficPolicy:
       mode: ALLOW_ANY
    enableTracing: true
    defaultProviders:
      metrics:
        - prometheus
      tracing: []
    accessLogFile: /dev/stdout
    accessLogEncoding: JSON

이스티오 오퍼레이터에서 accessLogEncoding 필드를 건드려서 출력 로그 형식을 지정할 수 있다.
이렇게 설정에서 JSON이라고 명시를 해준다.

이제는 최소한 키값쌍으로 나오니 어떤 값이 무얼 뜻하는지 알기 쉽다.
에러가 발생하는 한 줄만 뜯어서 살펴본다.

k logs -n istio-system istio-ingressgateway-6567675ffd-g6knh | tail - -n 1 | jq

일단 노란색 박스를 통해 현재 응답 상황을 명확하게 확인할 수 있다.

엔보이에서 UT는 UpstreamRequesTimetout으로, 게이트웨이에서 카탈로그로 요청을 보냈으나 시간이 너무 오래 걸려서 504처리로 커넥션을 끝냈을 것을 짐작할 수 있다.

이게 기본 로그 정보고, 추가적인 정보를 더 얻고 싶다면 로깅 수준을 높여주면 된다.
커넥션 풀, 라우팅과 hcm 관련 로그를 조금 더 자세히 파본다.

istioctl proxy-config log deploy/istio-ingressgateway -n istio-system \
--level http:debug,router:debug,connection:debug,pool:debug

~~뭐야 내 json 돌려줘요~~
갑자기 굉장히 많은 로그가 출력되기 시작한다.

복잡해보이지만, 그래도 각 로그를 추적할 단서로서 ConnectionId를 이용할 수 있다.

504에러가 발생한 커넥션을 추적해보자.

는 사실 바로 위 로그들이 해당 정보를 담고 있다.
카탈로그에서 요청이 돌아오지도 않았건만 게이트웨이에서는 타임아웃이라면서 커넥션을 먼저 끝내버리는 것을 볼 수 있다.
client disconnected가 클라 측의 종료를 나타낸다.
이 단계에서 이미 원인이 명확히 규명됐다고 볼 수 있겠다.

트래픽 패킷 추적

하지만 모든 이슈가 이리 해결되면 좋겠지만 안 된다면 정말 오고가는 패킷을 뜯어보는 방법이 가장 무식하면서도 효과적이다.

kubectl sniff -n istioinaction $CATALOG_POD -i lo

여기에서는 kubectl 플러그인 중 하나인 sniff를 활용해본다.

조금 놀랐던 게 이미 내 로컬에 있는 와이어샤크를 자동으로 실행을 시켜줬다.

몇 가지 패킷 중에서는 tcp 연결이 성립되고 http 요청까지는 찍혀놓고 이후에 바로 tcp 종료가 일어난 것을 확인할 수 있다.
주의할 것은 현재 이 트래픽은 엔보이와 어플리케이션 간의 연결이라는 것이다.

아예 인터페이스를 any로 걸고 보면 조금 더 다양한 정보를 확인할 수 있게 된다.
연결 도중에 RST, 즉시 TCP 연결을 끊으라는 메시지가 날아오는 것을 확인할 수 있다.

구체적으로는 게이트웨이에서 소스 ip(게이트웨이의 ip)를 가지고 RST를 보낸다.
(버츄얼 리소스는 보내는 측에 설정되는 리소스라는 것을 다시금 상기하자.)
38844는 소스 포트인데 실제로 해당 요청은 엔보이가 낚아채 42063 포트를 통해 어플리케이션에 전달한다.
0.5초가 지나자 게이트웨이에서 RST 플래그를 보냈고, 이 명령을 들은 엔보이는 어플리케이션과의 통신을 정상적으로 종료시켰다.

정말 연결을 끝내는 측은 게이트웨이이기 때문에 그쪽으로 보려고 했는데, sniff로는 정상적으로 볼 방법이 없다.
-p 옵션을 주면 파드를 복제하고 priveleged 권한을 통해 스니핑을 시작하는데, 어차피 실세 트래픽을 받는 건 복제 파드가 아니라 원본 파드이니..
임시 컨테이너로 sysadmin 권한을 가진 채로 들어가는 것도 시도해봤는데 실패했다.
원하는 파드의 내부 패킷을 마음대로 뜯을 방법이 없으려나..

로그를 통해서도 충분히 알 수 있긴 했으나, 이제 카탈로그의 응답이 답답해 게이트웨이에서 커넥션을 종료하고 있다는 것이 확실시됐다.

엔보이 텔레메트리

그럼 이제 대응책을 강구하기 위한 분석과 판단이 필요하다.
메트릭을 기반으로 실패가 얼마나 일어나고 있는지 파악해보자.
(패킷 추적은 귀찮고 번거로운 관계로 먼저 이렇게 원인을 추적하고 분석하는 것도 좋을 것 같다.)

서비스 대시보드에 보면 언뜻봤을 때 아무런 문제가 없어보인다.

그러나 저건 목적지를 기준으로 메트릭을 본 것이고, 카탈로그로 요청을 날리는 소스 입장에서는 성공률이 70퍼 언저리인 것을 확인할 수 있다.
타임아웃의 경우 이렇게 목적지와 소스의 결과가 다르게 나온다는 것에 유의하자.
실패율이 한 자리수가 나오는 것만 해도 불편한데, 두 자리수면 상당한 문제라고 볼 수 있겠다.

sort_desc(sum(irate(istio_requests_total{reporter="destination", destination_service=~"catalog.istioinaction.svc.cluster.local"}[5m]))by(response_code, pod, version))

현 실습에서 굳이 이렇게까지 할 필요까진 없지만, 결국 쿼리를 통해 위의 대시보드도 시각화되는 거니 프롬쿼리를 통해 조금 더 구체화시킨다.
간단하게 해석하자면,

카탈로그를 목적지로 향하는 이스티오 요청 총량 메트릭을 구한다.
여기에서 5분마다 순간 변화율을 구한다.
나온 값을 응답 코드, 파드, 버전 기준으로 그룹화시켜 각각 총합을 구한다.
내림차순 정렬한다.

카탈로그 중 2버전 중 하나가 말썽인 것을 확인할 수 있다.

결론

트러블슈팅을 할 때는 문제를 먼저 색적하고, 원인을 규명한 다음 해결책을 강구하는 순서로 나아가기 마련이다.
이스티오는 충분히? 복잡하기에 문제를 분석하기 위한 단계를 차근히 밟아나가며 대응을 해나가는 것이 매우 효과적인 전략이 될 것이다.
기본적으로 istioctl에서 많은 정보와 디버깅 기능을 제공하기에 이를 최대한 적극 활용하는 것이 추천된다.

번외 - 엔보이 디버깅 엔드포인트

엔보이 자체는 15000으로 관리자 페이지를 제공하지만 이스티오 차원에서 엔보이 별로 디버깅하는데 유용한 엔드포인트도 노출해주고 있다.
15020포트에서는 다양한 정보를 노출한다.

/healthz/ready 프록시의 준비 상태 체크
/stats/prometheus 엔보이와 에이전트의 메트릭 노출
- 설정을 하면 어플리케이션 메트릭도 이쪽으로 노출시킬 수 있다.
/quitquitquit 에이전트 프로세스 종료
/app-health/ 앱 컨테이너의 헬스상태 노출

이 엔드포인트는 앱 컨테이너의 헬스체크를 직접 할 때만 사용되는 게 아니라 kubelet이 실제로 접근하는 경로이기도 하다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: probe
  namespace: istioinaction
  labels:
    app: probe
spec:
  replicas: 1
  selector:
    matchLabels:
      app: probe
  template:
    metadata:
      labels:
        app: probe
    spec:
      containers:
        - name: probe
          image: nginx
          livenessProbe:
            httpGet:
              port: 80
          readinessProbe:
            httpGet:
              port: 80

이런 식으로 간단하게 워크로드를 만들어본다.
라이브네스, 레디네스 프로브가 설정돼있고 그냥 80번 포트로 가도록 돼있다.

그러나 막상 실제로 리소스를 적용하면 프로브쪽 정보가 바뀌어 있다.
승인 제어를 통해 프로브가 변형된 것이다.
헬스체크는 해당 경로를 통해 들어오고, 프록시가 해당 요청을 어플리케이션으로 전달하는 형태가 된다.

/debug/ndsz : istiod에서 Name Discovery Service API로 DNS 설정한 호스트네임 나열

현재 설정에는 아무것도 없기에 나오는 게 없다.

/debug/pprof/* : Go언어 디버깅 엔드포인트

고언어의 pprof 경로가 있다.
파일럿 에이전트가 go언어로 쓰여져 있기에 해당 기능을 지원한다.
고루틴은 몇개가 돌아가고 블록이나 뮤텍스가 얼마나 걸리는지도 확인할 수 있다.

번외 - 컨트롤플레인 디버깅 포인트

istiod도 여러 노출포인트가 있다.
여기에서는 프록시가 동기화가 언제 됐고 상태가 어떤지를 나타낸다.

8080포트에 이러한 정보를 볼 수 있는데, 정말 동기화됐다, 몇개가 푸시됐다 이런 정보들이 담겨있다.
만약 proxy status 명령어로 충분하지 않아서 조금 더 자세히 뜯어보고 싶다고 한다면 이런 식으로 보는 것도 하나의 방법이 될 것이다.

이름4	is-folder	생성 일자
E-이스티오 컨트롤 플레인 성능 최적화	false	2025-05-18 02:29
E-이스티오 컨트롤 플레인 메트릭	false	2025-05-18 15:45
istiod	false	2025-05-18 03:16
Istio Sidecar	false	2025-05-13 22:27